Data Analysis

Collaborative Coding 2

Jafet Belmont

School of Mathematics and Statistics

ILOs

By the end of this session you will be able to:

  1. Learn the basics about collaborative work using GitHub.

  2. Branching strategies

  3. Creating and deleting a Branch

  4. Merge conflicts

  5. “A better approach to resolving merge conflicts”

Inviting a collaborator

  1. Ask for the username of the person you’re inviting as a collaborator (the user name they used when they sign up for GitHub)

  2. On GitHub, navigate to the main page of the repository.

  3. Under your repository name, click Settings. If you cannot see the “Settings” tab, select the dropdown menu, then click Settings.

  4. In the “Access” section of the sidebar, click Collaborators.

  5. Click Add people.

  6. In the search field, start typing the name of person you want to invite, then click a name in the list of matches.

  7. Click Add NAME to REPOSITORY.

  8. The user will receive an email inviting them to the repository. Once they accept your invitation, they will have collaborator access to your repository.

Cloning a Repo

Cloning a project

  • Clone is a Git feature that allows a user to make a copy of a repository, including all the associated metadata on their computer so they can work on it.
  1. To do this you need to the URL of the repo you are trying to clone, and a location you want to put the cloned folder
  • Click on the green button labelled ‘Code’
  • Click on ‘Open with GitHub Desktop’ or copy the url

Cloning a project

  • Clone is a Git feature that allows a user to make a copy of a repository, including all the associated metadata on their computer so they can work on it.
  1. Open GitHub Desktop and paste the URL of the repository on GitHub populated.

  2. Choose where you would like the repository to be cloned to on your computer (needs an empty folder)

  3. Click ‘Clone’

Cloning a project

If an update is made, then all you need to do is resynchronise your local repo with the GitHub version

Branching

Branching strategies

  • Up until this point we have only committed changes to one branch -the default branch called main

  • If you are working on your own this can be a valid approach and avoids a lot of complexity in using Git.

  • Branches represents a distinct version of the main repository and enable a team to work on the same files at the same time.

  • Unlike Google Docs where you can track live changes, branches allow collaborators to work in isolation, not worrying about what others are up to, and when the time comes, integrate your changes into the default branch.

Branching strategies

This week we are going to learn how to create a branch and make changes to it, then integrate this branch back into the main branch. This is particularly helpful when working collaboratively.

  • In Git, a branch represents a distinct version of the main repository, serving as a snapshot of your changes.

  • When implementing new features or addressing issues, creating a new branch is the practice to isolate your modifications. 

  • When the work is complete, a branch can be merged with the main project. 

Creating a new branch

Lets start a simple example by creating a new repo.

Creating a new branch

Lets start a simple example by creating a new repo.

  • We begin with a single commit with the following content

Creating a new branch

  • Now commit this change to git

Creating a new branch

  • Next, let’s create a branch named shout based on this commit.

    • You do this be going to the main menu and selecting Branch > New Branch

Working on a branch

Lets modify the file by adding an explanation mark and commit the change!

  • Check the status of our shout branch:

Working on a branch

Our new changes appear on the new branch of our local repo.

  • Now we have made our change, we want to merge it back into the main branch

Merging a branch to main

  1. switch back to the main branch

Merging a branch to main

  1. start the ‘merge’

Merging a branch to main

  1. choose the branch that we want to merge back in (i.e., shout)

Merging a branch to main

  1. check that the version of our file in the main branch now has the exclamation mark

Merging a branch to main

  1. delete shout branch

Merging a branch to main

Our current (local) work flow:

  • Notice that the rejoining of the branches themselves then becomes a commit on the main branch, as this is the one we are updating.

A more complex example

  • A slightly more complex situation occurs when we try to make change to two branches and then merge

  • Let’s create a new branch converting the ! to a ?

A more complex example

  • Say we then update the file on question and get the following
  • Switching back to main then causes problems if you don’t commit your changes first!

  • If we switch branches without committing first will make us lose our local changes.

A more complex example

If we want to switch a branch before committing our changes the following dialog will appear:

GitHub Desktop offers us two options:

  • Leave my changes on question allows us to stash the changes (“save for later” kind of thing) and come back to the branch later and apply the stash.

  • Bring my changes to main automates the process of stashing the changes, switching to the desired branch, and applying the stash.

A more complex example

If we Bring my changes to main, this will automatically bring forward the changes we made in question to main.

  • Now that we are on main, we only need to commit these changes:

Recap

Lets re-cap what we have done so far.

  1. First, we created a example.md file in our main branch.

Recap

Lets re-cap what we have done so far.

  1. Then we created a shout branch and added an exclamation mark

Recap

Lets re-cap what we have done so far.

  1. We merged the shout branch into main

Recap

Lets re-cap what we have done so far.

  1. Create a question branch and changed the exclamation mark for a question mark

Recap

Lets re-cap what we have done so far.

  1. Add a second line to our file on the question branch without commit it. (This is equivalent to having unsaved changes in our file - see how our diagram has not changed)

Recap

Lets re-cap what we have done so far.

  1. Merge the question branch into main while bringing my changes to main

Recap

Lets re-cap what we have done so far.

  1. Now we save this changes into main (i.e., commit)

Recap

If you follow these steps through, the your local Git should look like something this:

Then, you can push this into GitHub and somebody else can pull these changes to their own machine.

Resolving conflicts

Merge Conflicts

In the last examples above we created a branch, made some changes and then integrated back into main.

However, what happens if you make a change to a line in a file on one branch, then you (or someone else) changes the same line of the same file on a different branch, what should Git do when you want to merge?

This is a so-called merge conflict.

Merge Conflicts

Suppose we create a new branch called capitalise and change the file to the following:

Merge Conflicts

Now imagine switch to main (or someone else is working there already) and add a full stop and commits this change before merging branches:

Merge Conflicts

We have the following:

Merge Conflicts

We have the following:

Merge Conflicts

Merge Conflicts

  • At this point Git doesn’t know what to do and passes back to us to decide
  • There are two approaches to deciding / fixing the problem

Merge Conflicts

We can choose to press ahead with the merge, like we did before

Merge Conflicts

GitHub Desktop will tell you which files need attention, and instruct you to open them in your preferred code editor.

The Continue Merge button is disabled! as we need to resolve the conflicts in our files.

Merge Conflicts

Open up example.md in your preferred editor and see what is happening:

  • There is no automatic way of fixing this, so you will have to change it manually deleting the merge conflict syntax
  • The line(s) between \(<<<<<<<\) and \(======\) here show what you already had.

  • The line(s) between \(=======\) and \(>>>>>>>\) is what was introduced by the other commit (in this case from the capitalise branch).

Merge Conflicts

Let’s manually edit our file to what we want, like a mixture of both changes.

Merge Conflicts

Once the special <<<<<<<====== and >>>>>>> syntax is removed from our files, GitHub Desktop detects that our merge conflict has been resolved and allows us to ‘Continue Merge’:

Merge Conflicts

Once the special <<<<<<<====== and >>>>>>> syntax is removed from our files, GitHub Desktop detects that our merge conflict has been resolved and allows us to ‘Continue Merge’:

Merge Conflicts

This is what we have done so far:

An alternative approach

  • There is a better way of doing it, that also demonstrates another use of branching
  • Let’s assume we have got to the following conflict

An alternative approach

  • Let’s avoid dealing with our merge conflict on main and instead fix it on goodbye
  • We do this my merging main into goodbye

How?

An alternative approach

  1. switch back to the goodbye branch.

An alternative approach

  1. choose main as our branch to merge into goodbye

An alternative approach

  1. Again, we get a conflict, but this time in goodbye

  2. Manually resolve it as before, this time with some Beatles lyrics in goodbye

An alternative approach

  1. GitHub Desktop has automatically detected that our merge conflict has been resolved:

An alternative approach

  1. Switch back to main

An alternative approach

  1. Our change can be merged without a conflict.

An alternative approach

  1. Our change can be merged without a conflict.

Re-cap to solve conflicts

  1. We have a merge-conflict

Re-cap to solve conflicts

  1. We have a merge-conflict
  2. We switch to goodbye and merge main goodbye after resolving the conflict.

Re-cap to solve conflicts

  1. We have a merge-conflict
  2. We switch to goodbye and merge main goodbye after resolving the conflict.
  3. We switch back to main and merge back goodbye main.

Group projects

Set up your Git

  • Don’t forget to invite JBelmont89 to watch your group projects.
  • No admin rights needed.
  • Don’t forget to accept your colleagues’ invitations.

Cloning

  • The colleagues who didn’t create the repo will have to clone it.
  • On GitDesktop go to File -> Clone Repository and find the repository on you Github.com.

Expectations for group project

  • Agree on a branching workflow – this will avoid confusion!

  • Example of common rules:

    • One branch, one owner: Each branch is “owned” by a single team member. This means that team members should not switch to another team member’s branch and start committing changes, unless they’ve been invited for a review (this can be done verbally).
    • Leave integration to the owner: Branches can only be merged by the owner. Possibly even after a successful review by other team members, since they’re the ones who know best when the task is complete.
  • This workflow allows each person to take ownership of their task.

  • We invite you to tell us about your shared rules: It shows you thought about them!

Merge and copy & paste

  • Do not copy and paste whole files saved on your machine instead of solving merge conflicts.

  • This is bad practice and you may end up dismissing your colleagues’ changes.